Method and Apparatus for Exchanging Routing Information and the Establishment of Connectivity Across Multiple Network Areas

ABSTRACT

Routes may be installed across multiple link state protocol controlled Ethernet network areas by causing ABBs to leak I-SID information advertised by BEBs in a L1 network area into an L2 network area. ABBs will only leak I-SIDs for BEBs where it is the closest ABB for that BEB. Where another ABB on the L2 network also leaks the same I-SID into the L2 network area from another L1 network area, the I-SID is of multi-area interest. ABBs will advertise I-SIDs that are common to the L1 and L2 networks back into their respective L1 network. Within each L1 and L2 network area, forwarding state will be installed between network elements advertising common interest in an ISID, so that multi-area paths may be created to span the L1/L2/L1 network areas. The L1/L2/L1 network structure may recurse an arbitrary number of times.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/258,238, filed Apr. 22, 2014, which is a divisional of U.S. patentapplication Ser. No. 13/526,907, filed Jun. 19, 2012, which is acontinuation of U.S. patent application Ser. No. 11/899,118, filed Sep.4, 2007, which claims the benefit of U.S. Provisional Patent ApplicationNo. 60/874,806, filed Dec. 14, 2006, entitled “Hierarchical Routing forPLSB,” and U.S. Provisional Patent Application No. 60/874,890, filedDec. 14, 2006, entitled “Recursive Provider Link State Bridging”, thecontent of each of which is hereby incorporated herein by reference.

TECHNICAL FIELD

The present invention relates to Ethernet networks and, moreparticularly, to a method and apparatus for exchanging routinginformation and the establishment of connectivity across multiplenetwork areas.

BACKGROUND

In Ethernet network architectures, devices connected to the networkcompete for the ability to use shared telecommunications paths at anygiven time. Where multiple bridges or nodes are used to interconnectnetwork segments, multiple potential paths to the same destination oftenexist. The benefit of this architecture is that it provides pathredundancy between bridges and permits capacity to be added to thenetwork in the form of additional links. However to prevent loops frombeing formed, a spanning tree was generally used to restrict the mannerin which traffic was broadcast on the network. Since routes were learnedby broadcasting a frame and waiting for a response, and since both therequest and response would follow the spanning tree, most if not all ofthe traffic would follow the links that were part of the spanning tree.This often led to over-utilization of the links that were on thespanning tree and non-utilization of the links that weren't part of thespanning tree.

To overcome some of the limitations inherent in Ethernet networks, alink state protocol controlled Ethernet network was disclosed in U.S.patent application Ser. No. 11/537,775, filed Oct. 2, 2006, entitled“Provider Link State Bridging,” the content of which is herebyincorporated herein by reference. As described in greater detail in thatapplication, the nodes in a link state protocol controlled Ethernetnetwork exchange hello messages to learn adjacencies of other nodes onthe network, and transmit link state advertisements to enable each nodeon the network to build a link state database. The link state databasemay then be used to compute shortest paths through the network. Eachnode then populates a Forwarding Information Base (FIB) which will beused by the node to make forwarding decisions so that frames will beforwarded over the computed shortest path to the destination. Since theshortest path to a particular destination is always used, the networktraffic will be distributed across a larger number of links and follow amore optimal path for a larger number of nodes than where a singleSpanning Tree or even multiple spanning trees are used to carry trafficon the network.

When customer traffic enters a provider network, the customer MACaddress (C-MAC DA) is resolved to a provider MAC address (B-MAC DA), sothat the provider may forward traffic on the provider network using theprovider MAC address space. Additionally, the network elements on theprovider network are configured to forward traffic based on Virtual LANID (VID) so that different frames addressed to the same destinationaddress but having different VIDs may be forwarded over different pathsthrough the network. In operation, a link state protocol controlledEthernet network may associate one VID range with shortest pathforwarding, such that unicast and multicast traffic may be forwardedusing a VID from that range, and traffic engineering paths may becreated across the network on paths other than the shortest path, andforwarded using a second VID range. The use of Traffic Engineered (TE)paths through a link state protocol controlled Ethernet network isdescribed in greater detail in U.S. patent application Ser. No.11/732,381, filed Apr. 3, 2007, entitled “Engineered Paths In A LinkState Protocol Controlled Ethernet Network”, the content of which ishereby incorporated herein by reference.

Large networks may be broken into smaller areas. Routing within a givenarea may be implemented independent of the other areas to enable therouting tables on the network elements within that area to be kept to areasonable size and as a consequence the time to compute forwardingtables bounded as the network grows. Recognizing that some routes mayneed to span across multiple areas, however it may be desirable toprovide a way that will enable the control planes of the multiple areasto coordinate the exchange of information to enable forwarding paths tobe established across multiple network areas.

SUMMARY OF THE INVENTION

One aspect of Provider Link State Bridging that facilitates multiplearea operation is that community of interest information in the form ofthe I-SID is incorporated into the routing system. This allows bridgeson the boundaries between areas, called Area boundary bridges (ABBs), tobe able to determine which community of interests are local to the area,and which span multiple areas. This provides the ABBs and Backbone CoreBridges (BCBs) with sufficient information to determine which services,and therefore associated Backbone Edge Bridges (BEBs), actually requiremulti-area connectivity and which do not, and only instantiateforwarding state for those that do.

An aspect of the IS-IS protocol (which is a preferred embodiment) thatfacilitates multi area operation is that the area structure ishierarchical, which simplifies the task of providing loop freesymmetrical connectivity between BEBs in different areas. IS-IS uses atwo level hierarchy L1 and L2 where L1 can be considered to be thenetwork edge, and L2 the backbone. In IS-IS, the formal interfacebetween an L1 and L2 is defined as being on a connection, not within anode. In this document an ABB is defined as a bridge operating both L1and L2 routing instances. Optionally, according to an embodiment of theinvention, the L2 network may be further formed as a second layerL1/L2/L1 network so that the multi-area network structure may recursesuch that the L2 network layer of a lower layer (Layer X) is formed as aL1/L2/L1 set of network layers referred to as a higher layer (Layer X+1)network. Recursion of this nature may occur multiple time to enable ahierarchical network structure to be developed.

Routes may be installed across multiple link state protocol controlledEthernet network areas by causing Area Boundary Bridges (ABBs), todetermine which Backbone Edge Bridges (BEBs) it is closest to, and selfselect to represent those closest BEBs into the other adjacent area.That the network self elects P2P connectivity out of a given areasimplifies the task of providing overall bi-directional symmetry. Sincethere is only one path out of an area for a given BEB, there will onlybe one path across the root or L2 area to perform inter-areainterconnect of any two BEBs.

Each ABB will leak community of interest identifiers, such as I-SIDinformation, received within an L1 network from the BEBs that itrepresents into an adjacent L2 network. The ABB will also listen on theL2 network for community of interest identifiers from other ABBs on theL2 network. When two or more ABBs advertise the same community ofinterest identifier in the L2 network, the route is of multi-areainterest. Each ABB will then advertise the matching community ofinterest identifier into its respective L1 network to cause a pathwithin the L1 network to be established between the BEB and ABB in theL1 network. Similarly, a path will be established in the L2 networkbetween ABBs that have advertised common community of interestidentifiers. Within the L1 network area, Backbone Core Bridges (BCBs)will install forwarding state if they are on a shortest path between aBEB and its closest ABB for those BEBs that host community of interestidentifiers that are associated with multi-area routes. BCBs within theadjacent L2 network area will establish shortest path forwarding statebetween ABBs advertising common community of interest identifiers, tothereby establish the routes through the adjacent network area. ABBs mayadditionally summarize BEB rooted multicast trees such that the set oftrees for a given community of interest identifiers transiting the ABBis condensed into a common tree rooted on the ABB. One example of acommunity of interest identifier that may be used in connection with anembodiment of the invention is the I-SID. Although this embodiment willbe described in considerable detail, the invention is not limited to animplementation that utilizes the I-SID as the community of interestidentifier as other embodiments may use another type of community ofinterest identifier.

Further as an enhancement to scalability, a network may be configured toinclude multiple link state protocol controlled Ethernet network areas.As a frame enters a first of these network areas it may be encapsulatedusing MAC-in-MAC encapsulation for transportation across the firstnetwork area. The frame may further be encapsulated with a new MACheader upon transition from the first to a second network area andlearning used to establish the bindings between MAC addresses in thefirst area and MAC addresses in the second area. Advertisements in therouting system are used to construct multicast trees which are utilizedto scope the flooding and learning to the community of interestassociated with a given community of interest identifier such as I-SID.The MAC-in-MAC-in-MAC utilizes the MAC-in-MAC I-SIDs such that the outerMAC multicast address is selected according to an I-SID associated withthe frame and is therefore scoped to the community of interestassociated with the I-SID. By selecting the multicast MAC address forthe second network area to coincide with the frame's I-SID, the framemay be encapsulated to follow a multi-area path through the secondnetwork area. I-SIDs may be leaked between network areas to enable themulti-area routes to be established, and the encapsulation process maythen be used to enable frames to be formatted for transportation acrossthe network areas. The process may recurs multiple times if necessary byfurther encapsulation as the frame is transmitted to higher levels of anetwork hierarchy or, more specifically, toward the center of thenetwork. The process may be reversed as the frame is transmitted downthe network hierarchy toward its destination after leaving the center ofthe network.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the present invention are pointed out with particularity inthe appended claims. The present invention is illustrated by way ofexample in the following drawings in which like references indicatesimilar elements. The following drawings disclose various embodiments ofthe present invention for purposes of illustration only and are notintended to limit the scope of the invention. For purposes of clarity,not every component may be labeled in every figure. In the figures:

FIG. 1 is a functional block diagram of an example link state protocolcontrolled Ethernet network;

FIGS. 2 and 3 are a functional block diagrams of an example set ofinterconnected link state protocol controlled Ethernet network areasaccording to an embodiment of the invention;

FIG. 4 is a functional block diagram decomposition of an ABB thatimplements both partitioning of the network into areas and hierarchicalrouting and which shows a process used to enable community of interestidentifier information to be leaked between network areas so that pathsmay traverse between link state protocol controlled Ethernet networkareas according to an embodiment of the invention;

FIG. 5 is a functional block diagram of network element that may be usedas an Area Boundary Bridge (ABB) at a boundary between two link stateprotocol controlled Ethernet network areas according to an embodiment ofthe invention; and

FIG. 6 is a functional block diagram of a network configured to employrecursion to enable subdivision of the network according to anembodiment of the invention.

DETAILED DESCRIPTION

Using a link state protocol with 802.1ah to control the Ethernetbackbone network enables the Ethernet network to be scaled from the LANspace to the MAN, and to the WAN, by providing more efficient use ofnetwork capacity with loop-free shortest path forwarding. Rather thanutilizing a learned network view at each node by using the Spanning TreeProtocol (STP) algorithm combined with transparent bridging, in a linkstate protocol controlled Ethernet network the bridges forming the meshnetwork exchange link state advertisements to enable each node to have asynchronized view of the network topology. This is achieved via the wellunderstood mechanism of a link state routing system. The bridges in thenetwork have a synchronized view of the network topology, have knowledgeof the requisite unicast and multicast connectivity, can compute ashortest path connectivity between any pair of bridges in the network,and individually can populate their forwarding information bases (FIBs)according to the computed view of the network.

When all nodes have computed their role in the synchronized view andpopulated their FIBs, the network will have a loop-free unicast tree toany given bridge from the set of peer bridges (those that requirecommunication to that bridge for whatever reason); and a both congruentand loop-free point-to-multipoint (p2mp) multicast tree from any givenbridge to the same set or subset of peer bridges per service instancehosted at the bridge. The result is the path between a given bridge pairis not constrained to transiting the root bridge of a spanning tree andthe overall result can better utilize the breadth of connectivity of amesh. In essence every bridge roots one or more spanning trees whichdefine unicast connectivity to that bridge, and multicast connectivityfrom that bridge.

Link state protocol controlled Ethernet networks provide the equivalentof Ethernet bridged connectivity, but achieve this via configuration ofthe network element FIBs rather than by flooding and learning. As suchit can be used by emerging standards such as IEEE (Institute ofElectrical and Electronics Engineers) 802.1ah draft standard entitledProvider Backbone Bridging or MAC-in-MAC with configured forwarding ofB-MACs (Backbone MAC) and trivial modifications to the BEB adaptationfunction, to map client broadcast behavior to multicast, such thatclient Ethernets can utilize the connectivity offered by the link stateprotocol controlled Ethernet network without modification. MACconfiguration may be used to construct shortest path loop-freeconnectivity (for both unicast and multicast purposes) between a set of(slightly modified) 802.1ah provider backbone bridges in order toprovide transparent LAN service to the C-MAC (Customer MAC) layer orother layer networks that can use a transparent LAN service.

FIG. 1 is a functional block diagram of an example of a portion of alink state protocol controlled Ethernet network 10. As shown in FIG. 1,the network 10 in this example includes a plurality of network elements12, interconnected by links 14. The network elements 12 exchange hellomessages to learn adjacencies of other network elements, and exchangelink state advertisements to enable each node to build a link statedatabase that may be used to calculate shortest paths between ingressand egress nodes through the network. Additional details associated withan example link state protocol controlled Ethernet network are providedin U.S. patent Ser. No. 11/537,775, filed Oct. 2, 2006, entitled“Provider Link State Bridging” the content of which is herebyincorporated herein by reference.

Two examples of link state routing protocols include Open Shortest PathFirst (OSPF) and Intermediate System to Intermediate System (IS-IS),although other link state routing protocols may be used as well. IS-ISis described, for example, in ISO 10589, and IETF RFC 1195, the contentof each of which is hereby incorporated herein by reference. Althoughthere are current versions of this protocol, the invention is notlimited to an implementation based on the current version of thestandard as it may be adapted to work with future versions of thestandard as they are developed. Similarly, the invention is not limitedto an implementation that operates in connection with one of theseparticular protocols as other protocols may be used to exchange routinginformation as well.

In addition to installing shortest path unicast forwarding state, thenodes may also install forwarding state for multicast trees on thenetwork. An example of a way to implement multicast in a link stateprotocol controlled Ethernet network is described in greater detail inU.S. patent application Ser. No. 11/702,263, filed Feb. 5, 2007,entitled “Multicast Implementation in a Link State Protocol ControlledEthernet Network” the content of which is hereby incorporated herein byreference. As described in that application, link state advertisementsmay be used to advertise multicast group membership to cause forwardingstate for a multicast group to be installed on the network. Inparticular, each source for a given multicast group may be assigned adestination MAC Address (DA) that is used to forward the frames on thenetwork. The nodes on the network install forwarding state for thesource/group tree if they happen to be on a shortest path from themulticast source to one of the destination nodes advertising vialinkstate “interest” in the multicast group.

Interest in a multicast may be based on the community of interestidentifier such as the I-SID, such that a node on the network willinstall forwarding state for a multicast group when it is on a shortestpath between a source and destination that have both advertised interestin the community of interest identifier associated with the multicastgroup. The forwarding state, however, is based on the multicast DA andVID associated with the multicast. In operation, when an interior nodereceives a frame it will perform a lookup in its Forwarding InformationBase (FIB) based on the destination address (DA) and VID associated withthe frame, and forward the frame accordingly. As mentioned above,although an embodiment of the invention will be described in which theI-SID is used as a community of interest identifier, the invention isnot limited to this embodiment as other types of community of interestidentifiers may also be used.

Traffic engineering may be used to create paths that do not necessarilyfollow only the shortest path on a link state protocol controlledEthernet network. Forwarding state for the traffic engineering paths maybe differentiated from forwarding state that was installed in connectionwith implementation of the shortest path routing protocol by identifyingthe traffic engineering forwarding state using a different VID. One wayof creating traffic engineering paths through a link state protocolcontrolled Ethernet network is disclosed in U.S. patent application Ser.No. 11/732,381, filed Apr. 3, 2007, entitled “Engineered Paths In A LinkState Protocol Controlled Ethernet Network,” the content of which ishereby incorporated herein by reference.

When a frame arrives at a network element, for example if customernetwork element I were to transmit a frame to customer network elementJ, the frame will be received at the provider network element F. Networkelement F will determine if it knows which of the nodes on the providernetwork are able to reach the customer MAC address of destination node J(C-MAC). If F has already learned that provider network element E isable to reach customer network element J, network element F will add aMAC header to perform Mac-in-Mac encapsulation of the customer frame.The outer header will include the destination MAC address of networkelement E to cause the frame to be forwarded on the network.

Similarly, where the frame is a multicast frame the provider networkelement F will determine the provider multicast DA that should be usedto transmit the frame on the provider network. The ingress networkelement F will then transmit the frame across the provider network usingshortest path forwarding or, alternatively, using any available trafficengineered path through the network. The ingress node performsC-MAC→B-MAC resolution and encapsulates the client frame using a new MACheader such that the resultant encapsulated frame is addressed using theB-MAC addressing space. MAC-in-MAC encapsulation is well known in theart and a detailed description of the processes involved in this type ofencapsulation will therefore not be provided.

Where ingress node F does not know which provider node is able to reachcustomer node J, the ingress node will simply use the multicast treeassociated with the community of interest (or I-SID) to flood the packetto all other BEBs in the community of interest. Any subsequent messagefrom J will permit F to learn which provider DA to use for the outer MACheader. Optionally, a distributed HASH table may be used to store theC-MAC to B-MAC correlations so that the ingress node may transmit aquery to one or more nodes implementing the distributed HASH tablerather than broadcasting an address resolution request. One way ofimplementing a distributed HASH table is disclosed in U.S. patentapplication Ser. No. 11/714,508, filed Mar. 6, 2007, entitled“Distributed Storage of Routing Information in a Link State ProtocolControlled Ethernet Network”, the content of which is herebyincorporated herein by reference.

As the network increases in size, and larger numbers of nodes areincluded in the network, it may be desirable to divide the network intotwo or more smaller areas. This allows the control plane to be separatedinto two or more instances, so that the routing updates may be containedwithin the smaller network area and changes within one area do notperturb the adjacent areas. From a routing perspective this isadvantageous as the number of link state advertisements may be reduced,the size of the link state databases may be reduced, and the overallspeed of convergence of the network upon change in topography may beincreased. However, dividing the network into two or more network areashas a disadvantage, in that the establishment of connectivity that spansbetween the network areas needs to be accommodated.

Once the network passes a certain size, sub-division may not besufficient in and of itself to solve scalability issues, and it may benecessary to reduce the amount of state in the core of the network (L2network) in order to continue to grow the network. This can be achievedby hierarchically recursing the network (MACinMACinMAC) both at thecontrol plane and data planes and, in the preferred embodiment, re-usingMAC learning as per 802.1ah in order to establish the bindings betweenthe B-MAC layer and the further recursed MAC layer.

A loop in the forwarding path for Ethernet can be catastrophic if theforwarding path is a multicast path. Therefore it is advantageous to usea routing hierarchy vs. mesh interconnect of peer networks as theproblem of ensuring loop freeness even in the presence of routing policyis simplified. Routing systems have such a concept, an exemplar beingthe notion of L1/L2 in IS-IS, in which L1 areas are only reachable viathe L2 area.

FIG. 2 illustrates one example of a communication network 10 in whichmultiple link state protocol controlled Ethernet network areas 20 areinterconnected via Area Boundary Bridges (ABB) 30. Specifically, in FIG.2, the network 10 includes a first set of link state protocol controlledEthernet network areas L1A, L1B, and L1C. The first set of link stateprotocol controlled Ethernet networks may be, for example, metropolitanarea networks, although the invention is not limited to this particularexample. The networks L1A, L1B, and L1C are interconnected by anotherlink state protocol controlled Ethernet network L2. The L2 network maybe, for example, a provider core network configured to interconnect theL1 networks. The invention is not limited to the particular exampleshown in FIG. 2, as the network of FIG. 2 is merely intended toillustrate one example environment in which the invention may beimplemented. In IS-IS, the formal interface between an L1 and L2 isdefined as being on a connection, not within a node. In this document anABB is defined as a bridge operating both L1 and L2 routing instances.

Customers connect to the networks via Backbone Edge Bridges (BEBs) 32.Within the network, connectivity is established via Backbone CoreBridges (BCBs) 34. Assume, as shown in FIG. 2, that a customer 40 thatconnects to network L1A via BEB-A would like to be able to communicatewith customer 42 that connects to network L1-B via BEB-B, and would liketo be able to communicate with customer 44 that connects to network L1-Bvia BEB-C. To enable communication of this nature, it will be necessaryto establish a route between A and B via network areas L1-A, L2, andL1-B, and similarly to establish a route between A and C via networkareas L1-A, L2, and L1-B.

There are a number of constraints to be considered in a multi-areasolution. Unlike (for example) phone numbers, Ethernet MAC addressescannot be summarized whereby a shorthand represents a group (such as 613area code is the area code designating all phone numbers in Ottawa,Canada). Further the network areas should implement symmetricalforwarding such that traffic is able to follow the same path in bothdirections through the network.

It will be assumed, for purposes of this example, that areas L1-A, L2,and L1-B are all link state protocol controlled Ethernet network areas,each of which is implementing its own link state routing protocolinstance. Thus, routing information is generally contained within thevarious network areas, and only a limited or summarized amount ofrouting information is exchanged between areas. However, as described ingreater detail herein, ABBs may allow community of interest identifierssuch as I-SIDs and some associated BEB information to be leaked betweenareas, so routes associated with the BEBs with I-SIDs in common may beestablished through more than one area. Specifically, since interest inthe I-SID may be leaked across the network boundary, route segments maybe established for the I-SID in each of the network areas thatcollectively form a multi-area route Since leaking of the I-SIDs may bedone without intervention by the network management system, theinter-area routes may be established automatically by the control planesof the multiple network areas.

According to an embodiment of the invention, ABBs on the border betweentwo networks advertise with each network area as being able to reach theother network. Thus, for example in FIG. 2, ABB-a and ABB-d each sit onthe boundary between network area L1-A and L2. Accordingly, each ofthese ABBs would advertise the ability to reach network area L2 withinnetwork area L1-A, and would advertise the ability to reach network areaL1-A within network area L2. According to one embodiment of theinvention, the ABBs may advertise network area L2 as a virtual BEB innetwork area L1, so that the BCBs may automatically determine which ABBshould handle traffic for a given set of closest BEBs by installingforwarding state for shortest paths between the closest BEBs and thevirtual BEB advertised by the ABBs. In this manner the L1 network mayself-select ABBs to represent sets of BEBs into the adjacent L2 networkarea. If all ABBs advertise the network area L2 as the same virtual BEB,then shortest paths from the BEBs in network area L1 will automaticallybe installed via the ABB that is closest to the virtual BEB, and hencefrom the set of BEBs that are closest to a particular ABB.

The ABBs self-select to represent particular BEBs in L1 by determiningwhich ABB is closet to each BEBs in L1. Thus, for example in FIG. 2,ABB-a is closest to BEB-A. Thus, routes from A that are required to passout of network area L1-A will be installed via the Backbone Core Bridges(BCBs), such as BCB-A′, to pass through ABB-a. Similarly, routes fromBEB-D will be installed via ABB-d. There are many ways to do this, butthe simplest (and the one requiring no special rules in the BEBs andBCBs in L1) is that L2 is represented into L1 as a single virtual BEBconnected to the ABBs with equal cost links.

There are specific rules for how ABBs leak information between areas. AnABB closest to a BEB in L1 will advertise the I-SIDs and BEB MACaddresses associated with that area into L2, this is without aprioriknowledge of what I-SIDs are of multi-area interest. ABBs will only leakBEB and I-SID information collected from other L1 areas from L2 into L1where one or more BEBs in L1 have already indicated interest in theI-SID. Therefore the nodes in L2 will have a complete map of I-SIDs andBEBs in the control plane. The nodes in L1 will have a map of only thoseBEBs and I-SIDs of local area interest and those that are genuinelymulti area.

One can see from the above that in L2, the appropriate dataplaneconnectivity will be built per community of interest identifier, i.e.per I-SID, between the ABBs electing to represent the associated BEBs inL1. Similarly in L1, the ABBs representing BEBs in other L1s will havethe appropriate connectivity built to include the local BEBs that arepart of the same community of interest as identified by the community ofinterest identifier.

BEBs on the L1 network area will advertise interest in a community ofinterest identifier, such as an I-SIDs, via link state advertisements orusing other messages in the L1 network area. In this example, it will beassumed that the community of interest identifier is an I-SID. Othercommunity of interest identifiers may be used as well.

The ABBs receive the messages indicating that one or more BEB on the L1network area is interested in an I-SID. The ABB will leak I-SIDs learnedon the L1 network area that have been advertised by those BEBs that areclosest to it, into the L2 network area. By only advertising I-SIDsadvertised by the set of BEBs that are closest to it, the L2 network maylearn which ABB should be used to forward traffic on the route to theBEB. The ABB will also listen for I-SIDs advertised by other ABBs on theL2 network area. Where more than one ABB respectively attached to adifferent L1 on the L2 network area has advertised interest in the sameI-SID, the I-SID is of multi-area interest. The detection of an I-SID inmore than one L1 ensures that the L2 network doesn't install forwardingstate between two ABBs on the same L1 network. If a single L1 has morethan one ABB, the internal topology of that L1 may cause more than oneABB to advertise the I-SID into L2, but this must be ignored in L2unless a different L1 also advertises that I-SID. In this instance, ABBsthat have advertised the I-SID in the L2 network will also advertise theI-SID back into its attached L1 network area, so that connectivity inthe L1 network area may be established from the BEB to the ABB in the L1network area. If multiple ABBs advertise an I-SID back into L1,connectivity between the ABBs themselves for that I-SID is notestablished in L1. In the example of FIG. 2, connectivity between ABB-band ABB-c is not established in L1-B.

In the Example shown in FIG. 2, it will be assumed that BEB-A hasadvertised an interest in I-SID-x in network area L1-A, and that BEB-Band BEB-C have advertised an interest in I-SID-x in network area L1-B.ABB-a, ABB-b, ABB-c will all advertise interest in all I-SIDs into L2that are advertised by BEBs which they represent. Thus, in this example,ABB-a will advertise MAC-BEB-A/I-SID-x, ABB-b will advertiseMAC-BEB-B/I-SID-x, and ABB-C will advertise MAC-BEB-C/I-SID-x. ABB-a,ABB-b, and ABB-c will all determine that I-SID-x is of multi-areainterest, by receiving the advertisements from the other ABBs on L2, anddetermining that the I-SID is being advertised from both L1-A and L1-B.Accordingly, ABB-a will advertise MAC-BEB-B/I-SID-x, andMAC-BEB-C/I-SID-x into network area L1-A, and ABB-b and ABB-c willadvertise MAC-BEB-A/I-SID-x into network area L1-B. By causing each ABBto advertise all I-SIDs learned from its adjacent L1 network area intothe L2 network area, the ABBs on the L2 may determine which I-SIDs arerequired to extend between L1 network areas and selectively advertiseMAC/I-SID information for only those routes into their L1 network area.

An ABB will leak all I-SIDs of interest to their set of BEBs in L1 fromL1 into L2, ABBs in L2 will advertise all the L1 I-SIDs betweenthemselves BUT will only advertise I-SIDs from L2 into L1 when the sameI-SID is also already being advertised by that L1. Thus, the net resultis that within L1 all BEBs interested in a specific I-SID will haveconnectivity established by the routing system. Only if that I-SIDexists in another area will the ABBs advertise interest in that I-SIDinto that L1 (in which case connectivity out of the area via the ABBswill be constructed). Within the L2 network area, the BCBs will installconnectivity between ABBs of the different L1 areas that have advertisedinterest in the same I-SID, so that connectivity within the L2 networkmay be established. If any L1 has more than one ABB advertising an I-SIDinto L2, connectivity for that I-SID between those ABBs is notestablished in L2.

ABBs will advertise all I-SIDs and associated BEB information from L1into L2. The I-SID information that is advertised from the L1 networkarea into the L2 network area will be in the form of the ABB MACaddress, the I-SIDs and the BEB MAC addresses associated with the I-SID.When an ABB has received an I-SID advertisement from another ABB in L2and has also received an advertisement from the local L1 indicatinginterest in the same I-SID, it will advertise the I-SID and BEBinformation received from L2 into L1.

The I-SID will be advertised within network L2. Similar to how singlearea solution works BCBs within area L2 will install forwarding state toenable shortest paths to be created between ABBs attached to differentL1 areas that are advertising interest in the same I-SID. Thus, forexample, assume that ABB-a, ABB-b, and ABB-c all advertise interest inI-SID=x. BCB-1 will recognize that it is on a shortest path between twoABBs that have advertised interest in a common I-SID and installforwarding state to enable frames to be forwarded from ABB-a to ABB-band vice versa. Similarly, BCB-2 will install forwarding state to enableframes to be forwarded from ABB-a to ABB-c and vice versa.

ABB-b and ABB-c will leak the I-SID from network area L2 into networkarea L1-B as if it was advertised from a virtual BEB located behind ABBsb&c. BCBs within network L1-B will then install forwarding state if theyare on shortest paths between a BEB that has advertised interest in anI-SID and the virtual BEB (which the ABB has advertised as alsointerested in the I-SID).

Note, in this regard, that by causing the ABBs to self-select which BEBsto represent in connection with routes that exit L1-B, parallel pathshave been created between ABB-b and BEB-B, and ABB-c and BEB-C. However,using multiple ABBs to reach different BEBs will not cause forwardingconflicts as what is actually being created is a spanning tree to thevirtual BEB that represents L2, which naturally results in routesbetween BEBs and ABBs being only installed from a BEB to the closestABB. Where there are equal cost paths between a given BEB and two ormore ABBs, the routing system will use a normal intra area tie breakingmechanism to determine which ABB should represent the BEB in theadjacent area.

I-SIDs are commonly associated with multicast connectivity.Specifically, a given multicast may be established on a network bycausing those BEBs interested in the multicast to advertise interest inthe I-SID associated with the multicast. Forwarding state will then beinstalled for the multicast as described in greater detail in U.S.patent application Ser. No. 11/702,263, as mentioned above. Othercommunity of interest identifiers may be used instead of the I-SID andthe invention is not limited to an implementation that uses the I-SID asthe community of interest identifier. As mentioned previously, it isdesirable to leak knowledge of BEBs between areas but in a mechanismthat minimizes how changes in one area perturbs another. One way to dothis is to simply associate the BEBs with the ABB in the peer area as ifthey were co-located, so that no knowledge of the topology of the peerarea (in the form of actual metrics) need be shared between the areas.It has been simplified to simply associating a BEB with the closest ABB.One consequence of this is that the multicast tree for a given I-SIDrooted at an ABB will be identical for all BEBs that are behind the ABB.This means that scalability can be enhanced by using a commondestination multicast address for those multicast flows for a givenI-SID that transit an ABB.

Since the ABBs may represent multiple multicasts for its set of closestBEBs, it may summarize the multicasts when leaking routing informationinto the adjacent area L2. For example, ABB-a may summarize multicastrouting information mMAC(BEB, I-SID) by advertising instead mMAC(ABB,I-SID). Specifically, the ABB may substitute its own DA for the DA ofthe BEB for the given I-SID. This may also be repeated at the boundarybetween L2 and L1. So to illustrate:

-   -   Going from L1 to L2 the multicast tree in L2 rooted at a given        ABB is common to all BEBs in the L1 that were closest to that        ABB.    -   Going from L2 to L1, the multicast tree in L1 rooted at a given        ABB is common to all closest ABBs in L2 each of which roots a        tree that is common to all closest BEBs in the given L1.    -   No ABB on a given area boundary is ever a leaf on a multicast        tree rooted on another ABB on that area boundary, either in L1        or L2.

From a path construction standpoint in the L1-A network, BCB-A′ willdetermine that it is on a shortest path from BEB-A to L2 (via ABB-a).BCB-A′ also will determine that BEB-A and ABB-a have an I-SID in common.Thus, BCB-A′ will generate a multicast group address for BEB-A/I-SID=x.It will also install unicast addresses for remote BEBs that haveadvertised an interest in I-SID-X (BEB-B and BEB-C in this example),will install a unicast address for local BEB-A, and will generate amulticast address for ABB-a/I-SID=x.

In the L2 network, BCB-1 will determine that it is on the shortest pathbetween ABB-a and ABB-b in L2 and that both have an I-SID (I-SID=x) incommon. BCB-1 will generate multicast addresses for ABB-a/I-SID=x andABB-b/I-SID=x and install unicast addresses for BEB-A and BEB-B.

Within a given L1 network, such as network L1-B, multiple ABBs mayadvertise interest or knowledge of a given I-SID. To enable BCBs withinthe network (L1-B network) to install forwarding state, the ABBs willadvertise the I-SID in connection with the virtual BEB representing theL2 network. This will allow the BCBs to only install forwarding statefor routes that span between areas through the closest ABB to theinterested BEB. This also prevents multiple paths from being installedbetween a given BEB and more than one ABB, since only one shortest pathfrom the BEB to the virtual BEB representing the L2 network will beinstalled, which will automatically go through the closet ABB to thatBEB. BCBs may be configured to not install forwarding state between ABBson a common network boundary (e.g. L1A-L2) even though two or more ABBsmay be advertising interest in the same I-SID.

Within L2, a given ABB may have many BEBs behind it that it isrepresenting into network area L2. To simplify the shortest pathcalculation on BCBs within network area L2, the BCBs will base therouting computations on the ABBs rather than on the BEBs the ABBsrepresent. In this instance, each BCB in L2 may determine if it is onthe shortest path between two ABBs, and if so whether the ABBs have anI-SID in common. If both of these conditions exist, the BCB may theninstall forwarding state for the multicast MAC address mMAC(ABB,I-SID=x) and the unicast MAC addresses uMAC(BEB) for those BEBsparticipating in the set of I-SIDs common to the two ABBs.

By causing the ABBs to self-select, unicast forwarding may beestablished across multiple domains without requiring explicit paths tobe set up. Rather, the routing system may implement the unicast pathsand enable forwarding state to be set up for the unicast paths evenwhere the unicast paths are required to span across multiple networkareas.

Since each network area has its own control plane, topology changes mayoften be isolated within a given network area. However, when a topologychange occurs that affects the election of ABBs for BEBs, the topologychange will also affect the adjacent network. Specifically, assume thata failure has occurred on network L1-A which has caused the shortestpath to L2 for BEB-A to change such that it transits ABB-d. In thisinstance the routing system in L1-A will cause a new shortest path to beestablished from BEB-A to ABB-d, and will cause ABB-d to advertiseBEB-A/I-SID=x into L2. This will cause new shortest paths to beestablished within L2 between ABB-a and ABB-d, and between ABB-c andABB-d. However, the network change will not affect the other L1 areas sothat local failures are able to be contained without cascading routingchanges throughout all areas of the network. Additionally, while somefailures in network L1-A may affect the routing system in L2, manyfailures in network L1-A will not affect the selection of ABBs for theBEBs, thus enabling the failure to be localized within L1-A so that therouting within L2 is not affected by the failure.

Once consequence of L2 being modeled as a virtual BEB in L1 is thatmultiple copies of a multicast packet may enter L1 from L2. However asthe overall behavior is that of a spanning tree rooted at the virtualBEB in L2, each BEB in L1 will still only receive one and only one copyof a given multicast packet.

Although an example has been provided, and described in detail inconnection with a particular example network shown in FIG. 2, theinvention is not limited in this manner as the techniques describedherein may be used in many different network settings to construct pathsacross multiple areas. Thus, the invention is not limited to animplementation in a network having network areas interconnected as shownin FIG. 2 but rather may be employed in connection with any network inwhich two or more link state protocol controlled Ethernet network areasare interconnected by one or more ABBs. Similarly, although the I-SIDwas used as an example of a type of community of interest identifierthat may be used to determine which communities of interest span betweenareas, the invention is not limited in this manner as other community ofinterest identifiers may be used as well.

Where a given BEB has two or more paths that are equal cost to two ormore ABBs and diverge, then it may be necessary to use different VIDs todifferentiate the traffic to the different ABBs. Other ways of resolvingconflicts between ABBs may be used as well and the invention is notlimited to an implementation that uses different VIDs to identifytraffic intended to the different ABBs.

ABBs and BCBs in L2 have an additional requirement in that an ABB on agiven area boundary cannot be a leaf for a multicast tree from an ABB onthe same area boundary. This prevents loops from forming at areaboundaries.

When traffic is forwarded from one network area into another networkarea, such as a L1 area into the L2 area, the traffic may beencapsulated so that forwarding over the second area occurs using thatarea's MAC addressing space. For example, when a frame is received byBEB-A from customer 16 that is addressed to customer 18 on BEB-B, theframe will initially have the destination address DA=C-MAC address ofcustomer 18. BEB-A will determine which BEB is able to reach thecustomer MAC address and encapsulate the customer frame using a providerEthernet header. For example, BEB-A may perform MAC-in-MAC encapsulationso that the frame may be forwarded over the L1-A network using providerMAC address space rather than customer MAC address space. There areseveral ways for the BEB-A to determine which BEB on the network is ableto reach customer 18 and the invention is not limited to the particularway in which this information is disseminated.

After the frame is transmitted across network area L1-A, it will arriveat ABB-a where it will be transmitted onto network area L2. It will beassumed, in connection with this, that the paths have been establishedas described in greater detail above. According to an embodiment of theinvention, ABB-a may further encapsulate the frame for transmissionacross the L2 network by performing MAC-in-MAC-in-MAC encapsulation sothat forwarding of the frame within the L2 network may use L2 MACaddress space. Specifically, ABB-a may determine which other ABB on L2is able to forward the frame on to its destination (B-MAC address) willdetermine the MAC address of the destination ABB on the L2 network(A-MAC address) and will then add a L2 MAC header to further encapsulatethe frame for transmission on the L2 network. This enables L1 addressesto be summarized onto L2 at the ABBs via encapsulation, so that BCBswithin L2 need only install routes based on L2 MAC (A-MAC) addressspace.

C-MAC/B-MAC learning in the L1 network space may be populated in anormal manner. Similarly, L1-MAC/L2-MAC (B-MAC address A-MAC address)learning may be populated by the normal learning process, such as byflooding a request for a L1-MAC/L2-MAC association and waiting for aresponse, or by using a distributed hash table.

FIG. 3 illustrates visually what is happening in connection with theencapsulation process. Specifically, the L1-A metrics remain local tonetwork area L1-A. L2 simply filters inter-L1 area routes by I-SID. Thisenables uMAC/mMAC congruence in L1, L2, and MAC-in-MAC-in-MAC. MulticastMAC addresses from L1-A are mapped via I-SID to a tree in L2. ABB-aneeds to know that the path to BEB-E is via ABB-e. This association maybe learned by flooding a request and waiting for a response. Flooding onnetwork areas is capped at ABB boundary nodes, however, so thatB-MAC/A-MAC association requests are not flooded into other areas of thenetwork. Once the B-MAC/A-MAC association is learned by the ingress ABB,the ABB may use that address to encapsulate frames for transmission onthe L2 network. Optionally, a self-assigned L2 multicast MAC address maybe used where a given I-SID has been advertised by more than onedestination ABB on the L2 network.

FIG. 4 illustrates the adaptation and interlayer learning and bindingfunctions between layers when the routing system recurses. As mentionedabove, the L2 network may become too large and it may be desirable tofurther recurse the network to allow the L2 network to be broken up intoa second level L1/L2/L1 network as shown in FIG. 6. FIG. 4 shows aprocess of enabling a frame to be encapsulated for transmission over arecursed L2 from L1 (where the unencapsulated layer is termed “layer X”and the encapsulated layer is referred to as “layer x+1”), and alsoillustrates a process of enabling a frame to be deencapsulated afterreceipt from the recursed network area L2 for transmission over networkarea L1 in a given layer.

FIG. 4 is a functional block diagram decomposition of an ABB thatimplements both partitioning of the network into areas and hierarchicalrouting. As such it communicates with peers in each partition L1 and L2of the current layer respectively. It also peers at the recursed level,layer X+1.

The L1 FIB for layer X is populated via routing exchange with peerdevices at L1 (including those communicated with across L2), similarlythe L1 FIB for layer X+1 (the encapsulating layer) is populated viarouting exchange with peer devices at layer X+1.

As shown in FIG. 4, when a frame is received from L1 at layer X, the ABBwill look to see if the layer X destination MAC cannot be resolved to anlayer X+1 MAC via lookup in the X to X+1 mapping FIB or if the frame isa broadcast or multicast frame. In these cases it will be encapsulatedusing the layer X+1 MAC of the BEB as the source and the multicast MACaddress for the I-SID used by the BEB in layer X+1 as the destination,and forwarded according to the layer X+1 FIB. If the layer X destinationMAC address can be resolved to a layer X+1MAC address the packet isencapsulated with the BEB MAC address as the source and the layer X+1MAC address obtained from the X to X+1 mapping FIB as the destinationand forwarded according to the layer X+1 FIB.

When a packet is received from layer X+1, the source MAC is associatedwith the layer X source MAC and the binding inserted into the X to X+1mapping FIB. The packet is deencapsulated and forwarded according to theinformation in the “layer X” FIB. It is the learning of X to X+1bindings via creative reuse of the 802.1ah MAC learning process thatobviates the need to explicitly communicate interlayer bindings in thelayer X+1 routing system.

It can be noted that the network can actually use this technique torecurse an arbitrary number of times. It can also be noted that what isreferred to in the example can also be sub-divided without recursion,such that a mixture of recursion, and subdivision at each layer ofrecursion can be employed to scale the network. This is illustrated inFIG. 6. For example, as shown in FIG. 6, the L2 network may be formed asa Layer X+1 L1/L2/L1 network having multiple L1(X+1) networksinterconnected by a L2(X+1) network area. Similarly, the L2(X+1) networkarea may be formed as a L1/L2/L1 set of (X+2) network areas. The processdescribed in connection with FIG. 4 may be used to implement theboundary between the L1(X) and L1/L2/L1 (X+1) layer, the boundarybetween the L1(X+1) and L1/L2/L1 (X+2) layer, or any further boundarybetween a network area and a further recursed L1/L2/L1 (X+n) layer.

From a routing standpoint, the UNI interface on the layer X network sideof the ABB will store layer X I-SID information received via the layer Xnetwork link state routing protocol in the layer X FIB. Similarly, theNNI interface on the layer (X+1) network side of the ABB will storelayer X+1 I-SID information received via the layer X+1 network linkstate routing protocol in the layer X+1 FIB. However, according to anembodiment of the invention, I-SID information is leaked between thelayer X and layer X+1 networks to enable the layer X+1 network toselectively install routes through the layer X+1 network for I-SIDs thatare common to different areas of the layer X network.

From a control plane perspective, the control plane information issummarized/aggregated across the layer X+1 network, to reduce the amountof information that must be handled on the control plane and installedin layer X+1 forwarding tables. This is advantageous from a scalingperspective, since the BCBs on the layer X+1 network are only require tostore forwarding information for Layer X+1 MAC addresses.

The both layer X exchange and layer X+1 exchange communicates I-SIDmembership of peer devices, which enables other ABBs to know whichI-SIDs should be leaked. The I-SID information is then used to constructmulticast connectivity in the layer X+1 network area and to learninterlayer bindings. Where the layer X network uses Mac-in-Macencapsulation, and the layer X+1 network uses Mac-in-Mac-in-Macencapsulation, the I-SID information is used to enable the ABB to learnthe Mac-in-Mac/Mac-in-Mac-in-Mac bindings so that the ABBs are able toencapsulate traffic on a per-I-SID basis.

Where alternate ABBs are to be used to interconnect the L1/L2 networks,the alternate ABB may be provided with a large metric so that it is notlikely to be chosen as providing the shortest path for any BEB on the L1network area. However, the alternate ABB may still leak I-SIDinformation into the L1 network area, and vice-versa, to enable thenetwork elements to have information about the ABB to enable fasterconvergence in the event of a failure on the primary ABB.

When an ABB fails, all traffic for an I-SID needs to be reconstructed.The traffic for the I-SID will need to be associated with a differentABB, which will require BCBs within the L1 network to install newforwarding state. One way in which this may be accomplished is to causethe new forwarding state to be installed using a different VID so thattwo sets of connectivity may be installed—a first set of paths for theprimary ABB and a second set of paths for the secondary ABB. Theforwarding state may be installed upon determination of a failure or,alternatively, may be pre-computed and installed before the failureoccurs. Installing the backup forwarding state using a different VIDenables the different forwarding state to be installed on the networkahead-of-time so that, upon failure of an ABB, the traffic may beautomatically switched over to the alternate paths by causing thetraffic to be tagged using the alternate VID.

FIG. 5 illustrates an example of a network element that may be used toimplement an embodiment of the invention. As shown in FIG. 5, thenetwork element includes a data plane 50 and a control plane 60. Thedata plane 50 generally includes Input/Output cards configured tointerface with links on the network, data cards 54 configured to performfunctions on data received over the I/O cards 52, and a switch fabric 56configured to switch data between the data cards/I/O cards. The controlplane contains a processor 62 containing control logic configured toimplement a L1 link state routing process 64 and a L2 link state routingprocess 66. Other processes may be implemented in the control logic aswell.

Data and instructions associated with the L1 link state routing process64 and a L2 link state routing process 66 may be stored as L1 routingsoftware 72 and L2 routing software 74 in memory 70. One or moredatabases or tables may be maintained by the ABB 30 as well to enablethe ABB to store information associated with the routes that have beeninstalled on the L1 and L2 networks. For example, the ABB 30 may includea L1 FIB 80, a L2 FIB 82, a L1 link state database 84, a L2 link statedatabase 86, and a L1/L2 FIB 88 containing community of interestidentifier (e.g. I-SID) associations between the forwarding informationin the two networks. The ABB may contain other software, processes, andstores of information to enable it to perform the functions describedabove and to perform other functions commonly implemented in a networkelement on a communication network.

The functions described above may be implemented as a set of programinstructions that are stored in a computer readable memory and executedon one or more processors on a computer platform associated with anetwork element. However, it will be apparent to a skilled artisan thatall logic described herein can be embodied using discrete components,integrated circuitry such as an Application Specific Integrated Circuit(ASIC), programmable logic used in conjunction with a programmable logicdevice such as a Field Programmable Gate Array (FPGA) or microprocessor,a state machine, or any other device including any combination thereof.Programmable logic can be fixed temporarily or permanently in a tangiblemedium such as a read-only memory chip, a computer memory, a disk, orother storage medium. Programmable logic can also be fixed in a computerdata signal embodied in a carrier wave, allowing the programmable logicto be transmitted over an interface such as a computer bus orcommunication network. All such embodiments are intended to fall withinthe scope of the present invention.

It is possible to envision variations of U.S. patent application Ser.No. 11/537,775, filed Oct. 2, 2006, entitled “Provider Link StateBridging,” with respect to how both the source and multicast group ofinterest are encoded in the dataplane which can be accommodated by thebasic techniques for shortest path tree construction described above,but with small modifications to the dataplane transfer functionperformed at ABBs.

In one variation, the multicast group address for a given group ofinterest is common to the entire group of BEBs that support the group ofinterest and the specific source BEB or ABB (multicast source) isencoded in the VLAN field. In this case, summarization of multicast MACaddresses is not possible, but summarization of VLAN information ispossible between areas. This is useful as such a technique is not frugalof VLANs and therefore a multi-area solution can dramatically increasethe scalability of the network. Summarization can be performed by wellunderstood VLAN translation at the ABB egress, whereby the ABBoverwrites the VLAN of a multicast packet with a VLAN value that hasbeen assigned to the ABB as a multicast source. The invention is notlimited by the particular way in which VLAN values are assigned to theABBs as multicast sources.

In this variation, the shortest path tree from a given BEB would have aunique VLAN wrapper per tree, so the shortest path tree from BEB A wouldsee (for example) all packets from BEB A tagged with VLAN 1, all packetsfrom BEB B tagged with VLAN 2 etc. Reverse path forwarding check (RFPC)would then be performed on the VLAN instead of the source MAC address.Packets that are required to transit between areas would flow through anABB and onto a shortest path tree in an adjacent area. Packets flowingon the shortest path tree from an ABB would simply be re-tagged with theVID assigned to the ABB as a multicast source, so that the ABB becomesthe “choke point” for the set of multicast sources that transit areasvia that ABB. Thus, given that there are 4000 odd VLAN tags available,the net result is that each “area’ or “level” could have 4000 nodes (sumof BEBs, BCBs, and ABBs), while summarization by the ABB (andreplacement of the VID by the ABB) thus permits each area to have itsown VID space and the network can grow in size by multiples of 4000nodes per area.

In another variation, the multicast group address is common as describedabove, but the source is only encoded in the source MAC address, and theVLAN used is common to all BEBs. In this case, no summarization ofmulticast addressing is possible at an ABB and the packets would bepassed unmodified.

It should be understood that various changes and modifications of theembodiments shown in the drawings and described in the specification maybe made within the spirit and scope of the present invention.Accordingly, it is intended that all matter contained in the abovedescription and shown in the accompanying drawings be interpreted in anillustrative and not in a limiting sense. The invention is limited onlyas defined in the following claims and the equivalents thereto.

What is claimed is: 1-21. (canceled)
 22. An Area Boundary Bridge (ABB),comprising: a set of first communication interfaces for coupling the ABBto a first network area, the first network area being controlled by alink state protocol; a set of second communication interfaces forcoupling the ABB to a second network area comprising a plurality ofBackbone Edge Bridges; at least one ABB processing element; and at leastone respective storage element coupled to each respective ABB processingelement, the at least one respective storage element storing respectiveinstructions for execution by the respective ABB processing element, therespective instructions comprising: instructions executable by therespective ABB processing element to receive, on any of the secondcommunication interfaces, community of interest identifiers associatedwith Backbone Edge Bridges (BEBs) reachable via any the secondcommunication interfaces; instructions executable by the respective ABBprocessing element to select, from the community of interest identifiersreceived on any of the second communication interfaces, respectivecommunity of interest identifiers for advertisement into the firstnetwork area from respective first communication interfaces; andinstructions executable by the respective ABB processing element toadvertise the respective community of interest identifiers from thefirst communication interfaces as being associated with a virtual BEB.23. The ABB of claim 22, wherein the instructions executable by therespective ABB processing element to advertise community of interestidentifiers from the respective first communication interfaces as beingassociated with a virtual BEB comprise instructions executable toadvertise the community of interest identifiers as being associated withthe virtual BEB to represent the second network area in the firstnetwork area as a BEB of the first network area.
 24. The ABB of claim23, wherein execution of the instructions executable to advertise thecommunity of interest identifiers as being associated with the virtualBEB to represent the second network area in the first network area as aBEB of the first network area results in the virtual BEB appearing toparticipate in the link state protocol of the first network area. 25.The ABB of claim 22, wherein: the respective instructions compriseinstructions executable by the respective ABB processing element toreceive on respective first communication interfaces respectivecommunity of interest identifiers associated with respective BEBs thatare reachable via the respective first communication interfaces; and theinstructions executable by the respective ABB processing element toselect, from the community of interest identifiers received on any ofthe second communication interfaces, respective community of interestidentifiers for advertisement into the first network area fromrespective first communication interfaces comprise instructionsexecutable to select community of interest identifiers that have beenreceived on both the respective first communication interfaces and anyof the second communication interfaces.
 26. The ABB of claim 22, whereinthe respective instructions comprise instructions executable by therespective ABB processing element to advertise from respective secondcommunication interfaces community of interest identifiers associatedwith BEBs of the first network area that are reachable via therespective second communication interfaces.
 27. The ABB of claim 26,wherein the community of interest identifiers associated with BEBs ofthe first network area that are reachable via the respective secondcommunication interfaces are community of interest identifiers receivedon first communication interfaces of the ABB.
 28. The ABB of claim 27,wherein the instructions executable by the respective ABB processingelement to advertise from the second communication interfaces communityof interest identifiers received on first communication interfaces ofthe ABB comprise instructions executable to advertise only community ofinterest identifiers associated with BEBs in the first network area thatare deemed closer to the respective ABB than to any other ABB coupled tothe first network area.
 29. The ABB of claim 28, wherein theinstructions executable to advertise only community of interestidentifiers associated with BEBs in the first network area that aredeemed closer to the respective ABB than to any other ABB coupled to thefirst network area comprise: instructions executable to receive, on thefirst set of communication interfaces from BEBs of the first networkarea, link state protocol advertisements comprising at least onerespective measure of distance associated with each BEB from which thelink state protocol advertisements are received; instructions executableto determine which BEBs are closer to the respective ABB than to anyother ABB coupled to the first network area based on the respectivemeasures of distance; and instructions executable to determine communityof interest identifiers associated with the BEBs that are closer to therespective ABB than to any other ABB coupled to the first network areabased on the respective measures of distance.
 30. The ABB of claim 22,wherein the first link state protocol controlled network area is a linkstate protocol controlled Ethernet network area.
 31. The ABB of claim22, wherein the first link state protocol controlled network iscontrolled by an IS-IS link state protocol.
 32. The ABB of claim 22,wherein the community of interest identifiers are service instanceidentifiers (I-SIDs).
 33. The ABB of claim 30, wherein the instructionsexecutable by the respective ABB processing element to advertisecommunity of interest identifiers received on second communicationinterfaces from the respective first communication interfaces compriseinstructions executable by the respective ABB processing element toadvertise a media access control (MAC) address of the ABB, respectiveI-SIDs received on the respective second communication interfaces, andrespective MAC addresses of Backbone Edge Bridges (BEBs) associated withthe respective I-SIDs.
 34. The ABB of claim 33, wherein the instructionsexecutable by the respective ABB processing element to advertise a mediaaccess control (MAC) address of the ABB, respective I-SIDs received onthe respective second communication interfaces, and respective MACaddresses of Backbone Edge Bridges (BEBs) associated with the respectiveI-SIDs comprise instructions executable to advertise a respective MACaddress of at least one virtual BEB and at least one respective I-SIDassociated with the at least one virtual BEB.
 35. The ABB of claim 22,wherein: the instructions executable by the respective ABB processingelement to advertise the respective community of interest identifiersfrom the first communication interfaces as being associated with avirtual BEB comprise instructions executable to send Level X link stateprotocol messages into the first network area; and the instructionsexecutable by the respective ABB processing element to receive, on anyof the second communication interfaces, community of interestidentifiers associated with BEBs reachable via any of the secondcommunication interfaces comprise instructions executable to receiveLevel X+1 link state protocol messages.
 36. The ABB of claim 22, whereinthe ABB maintains: Level X forwarding information for the first networkarea; Level X+1 forwarding information for the second network area; andLevel X/X+1 forwarding information comprising community of interestidentifier associations between the Level X forwarding information andthe Level X+1 forwarding information.
 37. The ABB of claim 36, whereinthe ABB maintains: Level X link state information for the first networkarea; and Level X+1 link state information for the second network area.38. The ABB of claim 36, wherein the instructions further comprise:instructions executable by the ABB processing elements to perform aLevel X link state routing process for the first network area; andinstructions executable by the ABB processing elements to perform aLevel X+1 link state routing process for the second network area. 39.The ABB of claim 22, wherein the storage elements are configured tostore: Level X forwarding information for the first network area; LevelX+1 forwarding information for the second network area; and Level X/X+1forwarding information comprising community of interest identifierassociations between the Level X forwarding information and the LevelX+1 forwarding information.
 40. The ABB of claim 39, wherein: the LevelX forwarding information is Level 1 forwarding information; the LevelX+1 forwarding information is Level 2 forwarding information; and theLevel X/X+1 forwarding information is Level 1/2 forwarding informationcomprising community of interest identifier associations between theLevel 1 forwarding information and the Layer 2 forwarding information.41. The ABB of claim 22, wherein the storage elements are configured tostore: Level X link state information for the first network area; andLevel X+1 link state information for the second network area.
 42. TheABB of claim 41, wherein: the Level X link state information is Level 1link state information; and the Level X+1 link state information isLevel 2 link state information.
 43. The ABB of claim 22, wherein theinstructions comprise: instructions executable by the ABB processingelements to perform a Level X link state routing process for the firstnetwork area; and instructions executable by the ABB processing elementsto perform a Level X+1 μlnk state routing process for the second networkarea.
 44. The ABB of claim 43, wherein: the Level X link state routingprocess is a Level 1 link state routing process; and the Level X+1 linkstate routing process is Level 2 link state routing process.